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SIP "cause" URI Parameter for Service Number Translation 
Abstract 


RFC 4458 (regarding SIP URIs for applications) defines a "cause" URI 
parameter, which may appear in the Request-URI of a SIP request, that 
is used to indicate a reason why the request arrived to the User 
Agent Server (UAS) receiving the message. This document updates RFC 
4458 by creating a new predefined value for the "cause" URI parameter 
to cover service number translation for cases of retargeting due to 
specific service action leading to the translation of a called 
service access number. This document also provides guidance, which 
was missing in RFC 4458, for using the "cause" URI parameter within 
the History-Info header field, since this use is mandatory in some IP 
networks’ implementations. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8119. 
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1. Introduction, Terminology, and Overview 


[RFC4458] defines a mechanism to identify retargeting due to call 
forwarding supplementary services. The "cause" URI parameter in the 
target URI identifies the reason for retargeting and has defined 
values equivalent to the TDM (Time Division Multiplexing) Redirecting 
Reasons [ITU-T_Q.763]. The concept of "retargeting" is defined in 
[RFC7044]. 


In the Public Switched Telephone Network (PSTN ) / Integrated 
Services Digital Network (ISDN), there is another kind of retargeting 
introduced by the Intelligent Network (IN) services based on a 
translation of the called number as mentioned in [ITU-T_Q.1214]. 
Indeed, IN aims to ease the introduction of new services (i.e., 
Universal Personal Telecommunication (UPT), Virtual Private Network 
(VPN), Freephone, etc.) based on greater flexibility and new 
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capabilities as described in [ITU-T_I.312_0.1201]. For these IN 
services, ISDN User Part (ISUP) introduced the "called IN number" and 
the "original called IN number" parameters to capture the information 
of the requested service access number prior its translation 
[ITU-T_Q.763]. 


The term "service access number" is used in this specification to 
refer to the dialable number by which a specific service is reached. 
This special number is not a globally routable number; therefore, it 
needs to be translated into a routable SIP or tel URI to process the 
session establishment. 


This specification proposes a solution to allow the identification of 
well-known services, such as premium or toll-free services that 
perform service access number translation, and to enable interworking 
with SIP signaling with the ISUP called IN number and original called 
IN number parameters. 


The mechanism will allow a SIP network to insert and convey the 
service access number requested before its translation to the final 
destination. 


In order to provide full call forwarding or access number translation 
services, usage of the "cause" URI parameter is only relevant within 
the History-Info header field defined in [RFC7044]. Because this 
relation has not been described in [RFC4458], this document provides 
guidance for using the "cause" URI parameter in conjunction with the 
History-Info header field. 


This document also answers a need expressed by the Third Generation 
Partnership Project (3GPP) [TS.3GPP.24.229] to identify the service 
access number. The procedures it defines are intended for networks 
that use 3GPP-defined services. Their use is undefined for other 
networks. 


2. Solution 


A new value for the "cause" URI parameter of the ’sip:’ or 'sips:’ 
URI schemes is defined for the "Service number translation" use case. 
This value may be used in a ‘’sip:’ or ’sips:’ URI inserted in the 
Request-URI and in the History-Info header field [RFC7044] when the 
URI is issued from a retargeting or a service access number 
translation by a specific service similar to PSTN/ISDN IN services 
that is not a call forwarding service. 


As defined in [RFC4458], the "cause" URI parameter must be encoded in 
the new target URI when generated by the service. 
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The ABNF grammar [RFC5234] for the cause-param and target-param 
parameters from [RFC4458] is summarized below (including updates 


described in [Err1409]). The Status-Code is defined in [RFC3261]. 
target-param = "target=" pvalue 
cause-param = "cause=" Status-Code 


The following value for this URI parameter is added to the existing 


ones: 
Fn t------— + 
| Cause | Value | 
Fn Feanora + 
| Service number translation | 380 | 
Fn fracties + 
3. Guidelines 


In order to help implementation of this solution for conveyance of 
the service access number, this document proposes guidance for usage 
of the "cause" URI parameter: guidance for the usage of the "cause" 
URI parameter in the request history information (in Section 3.1) and 
guidance for processing a service number translation service using 
the new "cause" URI parameter value (in Section 3.2). 


3.1. Interaction with Request History Information 


The History-Info header field defined in [RFC7044] specifies a means 
of providing the UAS and User Agent Client (UAC) with information 
about the retargeting of a request. This information includes the 
initial Request-URI and any retargeted URIs. This information is 
placed in History-Info headers as the request is retargeted and, upon 
reaching the UAS, is returned in certain responses. The History-Info 
header field enables many enhanced services by providing the 
information as to how and why a SIP request arrives at a specific 
application or user and to keep this information throughout the 
signaling path even when successive applications are involved. 


When a proxy inserts a URI containing the "cause" URI parameter 
defined in [RFC4458] into the Request-URI of a forwarded request (per 
[RFC7044]), the proxy must also copy this new Request-URI within a 
History-Info header field entry into the forwarded request; thus, the 
URI in that entry includes the "cause" URI parameter. Therefore, 
even if the Request-URI is replaced as a result of rerouting by a 
downstream proxy, the History-Info header field will still contain 
these parameters, which can be of use to the UAS. Note that if a 
proxy does not support generation of the History-Info header field or 
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ek 


if a downstream proxy removes the History-Info header fields, an 
application will only have access to the "cause" URI parameter if the 
request is not subsequently retargeted (i.e., it will be contained 
only in the Request-URI in the incoming request). The implications 
of the solution are further discussed in Section 3.2. 


In order to be able to filter specific entries among the history 
information, header field parameters have been defined in [RFC7044]. 
In particular, the "mp" and "rc" header field parameters have the 
following definitions: 


o When the new target was determined based on a mapping to a user 
other than the target user associated with the Request-URI being 
retargeted, the "mp" header field parameter is added. This allows 
the identification of retargets that are the result of an 
application decision on a user’s behalf and also retargets that 
are the result of an internal decision made by an application. 


o The "rc" header field parameter is added when the new target 
represents a change in Request-URI, while the target user remains 
the same. 


These header field parameters can be used in conjunction with the new 
"cause" URI parameter for certain applications, an example of which 
is provided in Section 4. 


When using the History-Info header field in conjunction with the 
"cause" URI parameter in a Request-URI, it is important to consider 
that the "cause" URI parameter is not the same parameter as the 
"cause" header field parameter included in the Reason header 
[RFC3326]. The "cause" header field parameter of the Reason header 
field should be added to a History-Info entry only when the 
retargeting is due to a received SIP response. 


Handling and Processing the Service Number Translation "cause" URI 
Parameter Value 


At the Application Server: 


When an application receiving a request that is addressed to a 
service access number changes the Request-URI into a routable 
number, it should insert within this new Request-URI a "cause" URI 
parameter value set to 380 "Service number translation". 

Following the process described in [RFC7044], the application 
server adds a new History-Info header field entry including the 
new Request-URI value including the "cause" URI parameter. It is 
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also possible for an application server to add a "target" URI 
parameter as defined in [RFC4458] with the initial value of the 
Request-URI received by the application server. 


Note that if the new Request-URI is further replaced by a downstream 
proxy for any reason and if the History-Info header field is not 
supported, the information of the service access number initially 
requested would be lost. Thus, it is strongly recommended to support 
the History-Info header field all along the signaling path. 


At the UAS: 


When the UAS receiving the request wants to retrieve the service 
access number by which it has been reached, first it should look 
for the "cause" URI parameter value 380 in the History-Info header 
field. This History-Info entry should also contain an "mp" or 
"re" header field parameter so that the UAS can find the requested 
service number in the History-Info entry having an index parameter 
value that matches this "mp" or "rc" header field parameter value. 
If, for any reason, there is no "mp" or "rc" header field 
parameter in the identified History-Info entry, the UAS can find 
the requested service number in the preceding History-Info entry. 


If the History-Info header is not supported or has been removed by a 
proxy for any reason, the UAS might be able to find the requested 
service access number before translation in either of the following 
ways, but there is no guarantee: 


o If the UAS is the direct target of the request coming from the 
application, the UAS ought to be able to find the service access 
number in the "target" URI parameter of the Request-URI if there 
is also a "cause" URI parameter set to 380 in this Request-URI. 


o If there is no "cause" URI parameter set to 380 in the Request-—URI 
and there is no History-Info header field, the UAS will not be 
able to reliably retrieve the service access number before 
translation. Some existing implementations are known to extract 
the number from the To header field. While that approach may work 
in some situations, it will not work in the general case because 
the To header field value is sometimes changed by intermediaries, 
and such a change is not always detectable. 
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4. 


Example 


In this section, an example is provided to illustrate the application 
of the new cause-param value. 


In this example, Alice calls her bank customer care. John is the 
person at the call center that answers the call. John is ina call 
center that manages several toll-free services, and he needs to know 
for which service Alice is calling in order to provide the 
appropriate welcome speech. 


Alice Toll-Free Service Atlanta.com John 


| INVITE F1 | | | 
[Stes a >| INVITE F2 | | 


* Rest of flow not shown * 


Figure 1: Service Access Number Translation Example 


Message Details 


F1 INVITE [2001:db8:9::2] -> Toll-Free Service 


In the initial request, the Request-URI contains the toll-free 
number dialed by Alice. 


INVITE sip:+18005551002@example.com;user=phone SIP/2.0 

Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf 

From: Alice <sip:+15551001@example.com; user=phone>; tag=9fxced76sl 
To: <sip:+18005551002@example.com; user=phone> 

Call-ID: c3x842276298220188511 

CSeq: 1 INVITE 

Max-Forwards: 70 

Contact: <sip:alice@[2001:db8:9::2]> 

Content-Type: application/sdp 

Content-Length: <appropriate value> 


[SDP Not Shown] 
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F2 INVITE Toll-Free Service -> Atlanta.com 


The toll-free application receives the request and translates 
the service number into a routable number toward the call center. 
The Request-URI is changed, and, in the new Request-URI, a 
"cause" URI parameter set to 380 is added. As there was no 
History-Info header field in the received request, 

the application creates a History-Info header with two entries: 
one for the received Request-URI and one for the new Request-URI. 


INVITE sip:+15555551002@atlanta.com; cause=380;user=phone SIP/2.0 

Via: SIP/2.0/TCP [2001:db8:a::2];branch=z9hG4bK-ik8 

Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf 

From: Alice <sip:+15551001@example.com; user=phone>; tag=9fxced76sl1 

To: <sip:+18005551002@example.com; user=phone> 

Call-ID: c3x842276298220188511 

CSeq: 1 INVITE 

Max-Forwards: 69 

Supported: histinfo 

History-Info: <sip:+18005551002@example.com; user=phone>; index=1 

History-Info: <sip:+15555551002@atlanta.com; cause=380; user=phone>; 
index=1.1;mp=1 

Contact: <sip:alice@[2001:db8:9::2]> 

Content-Type: application/sdp 

Content-Length: <appropriate value> 


[SDP Not Shown] 
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F3 


NOTE: 


INVITE Atlanta.com -> John 


The call center proxy routes the received request to John’s 
IP address by changing the Request-URI. When changing the 
Request-URI, the proxy adds a new entry in the History-Info 
header field. 


INVITE sip: john@[2001:db8:b::2] SIP/2.0 

Via: SIP/2.0/TCP [2001:db8:b::3]:5060;branch=z9hG4bKpxk7g 

Via: SIP/2.0/TCP [2001:db8:a::2];branch=z9hG4bK-ik8 

Via: SIP/2.0/TCP [2001:db8:9::2]:5060;branch=z9hG4bK74bf 

From: Alice <sip:+15551001@example.com; user=phone>; tag=9fxced76sl 

To: <sip:+18005551002@example.com; user=phone> 

Call-ID: c3x842276298220188511 

CSeq: 1 INVITE 

Max-Forwards: 68 

Supported: histinfo 

History-Info: <sip:+18005551002@example.com; user=phone>; index=1 

History-Info: <sip:+15555551002@atlanta.com; cause=380; user=phone>; 
index=1.1;mp=1 

History-Info: <sip:john@[2001:db8:b::2]>;index=1.1.1;rc=1.1 

Contact: <sip:alice@[2001:db8:9::2]> 

Content-Type: application/sdp 

Content-Length: <appropriate value> 


[SDP Not Shown] 


Line breaks are for display purpose only 


5. IANA Considerations 


[RFC4458] defines a "cause" URI parameter specified as having 
predefined values. This document defines a new value for the "cause" 
URI parameter: 380. 


IANA has modified the existing row for the "cause" URI parameter to 
add a reference to this document under the "SIP/SIPS URI Parameters" 
subregistry within the "Session Initiation Protocol (SIP) Parameters" 


registry: 
Parameter Name Predefined Values Reference 
cause Yes [RFC4458] [RFC8119] 
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6. 


7. 


7. 


Security Considerations 
The security considerations in [RFC4458] apply. 


If a privacy level of ’header’ is requested in the Privacy header 
field as described in [RFC3323], the "cause" URI parameter must be 
removed from the Request-URI to maintain the network-provided privacy 
requested. Privacy of the parameters, when they form part of a URI 
within the History-Info header field, is covered in [RFC7044]. 
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